010 Введение
- Что такое SRE
- Чем занимается SRE
- Какие цели ставятся перед SRE
SRE (Site Reliability Engineering) — инженерия по эксплуатации и обеспечению бесперебойной работы информационных систем. А так же представитель профессии SRE (Site Reliability Engineer).
Обеспечивать надежность работы можно не используя этот термин и без представителей этой профессии, которые по сути являются просто опытными инженерами-разработчиками (Software Engineer) как мы увидим позже. Но принципы, как именно и что мы будем делать в любом случае едины для всех и на рассмотрении этих принципов мы и сосредоточимся.
Понятие SRE появилось в Google. Они решали вопросы бесперебойной работы своих глобальных сервисов и решили, что у них сложилась достаточно стройная и полноценная практика, которую они решили описать и дать название.
Термин стал популярным, потому что Google добился огромной репутации надежности своих сервисов. Пользователи Интернет проверяют наличие доступа к сети по тому, работает ли Google-поиск — представить его сломанным практически невозможно.
Подробнее о их приемах пожно почитать в их книгах.
Большую часть времени мы будем посвещать облачным сервисам, которые работают в data-центрах. Именно они сейчас оказывают наибольшее влияние на наши жизни — мы живем жизни подключенных существ, которые всегда онлайн. Мы общаемся, покупаем, учимся, знакомимся, работаем в сети. Именно от этих приложений, котрые работают в больших датацентрах где-то далеко от нас наиболее зависят наши жизни. И обеспечение их бесперебойной работы — важная и востребованная задача.
Но клаундные приложения часто очень сложные из-за многих компонент, одновременно обслуживают огромное количество пользователей, обрабатывают огромное количество данных и потому используют очень много железа. Это могут быть тысячи и десятки тысяч нод. Все это приводит к тому, что если не принимать специальные меры, то такие сервисы постоянно ломаются.
Надежность постоянно конкурирует за ресурсы с другими характеристиками софта:
- скоростью поставки
- богатством функционала
- стоимостью разработки
С другой стороны, бесперебойная работа — не самоцель. Пользователям необходимо, чтобы функционал работал. С уменьшением количества влияние сбоев на пользовательский опыт тоже уменьшается, а уменьшать количество сбоев еще более становится все сложнее. Рано или поздно настигает состояние, когда еще большая надежность становится не выгодна всем. Пользователи не получают новый функционал, потому что ресурсы расходуются на дальнейшую полировку уже имеющегося, а компания при этом зарабатывает меньше, хотя делает такой же объем работы.
Представления о надежности зависят от страны, традиций, культуры. Есть культуры, где считается нормальным, когда какой-то сервис не работает, например, ночью. Я даже был пользователям такого банка. И это не очень сильно тревожило людей. В России банк, да и любой другой сервис, не работающий ночью, не выдержит конкуренции. Поэтому когда мы говорим "надежность", надо понимать, что это не какая-то объективная характеристика, а некоторое состояние, которое пользователи считают приемлимым для данного сервиса.
Так же может быть оправдано не думать про надежность в начале жизни стартапа. На том этапе другие приоритеты — получить пользователей, разработать функционал, закрепиться на рынке, доказать инвестору, что вы вернете и приумножите его вложения. Затем вдруг оказывается, что пользователей уже много, доходы появились, вы нужны миру и пользователям, а надежность все еще на уровне стартапа. Это может произойти резко – происходит разрыв надежности.
Аналогичная история случается с новым, экспериментальным функционалом больших компаний. Люди хотят попробовать и не думают про надежность в процессе разработки. Потом новый функционал становится востребованным и все то, на чем сэкономили начинает бить по надежности получившийся системы.
Корень всех бед
Основная причина ненадежности софта в том, что его делают люди. Причина любого сбоя — человеческие действия. Люди несовершенны, ошибаются, ленивы, пытаются сэкономить в результате получаемый результат далек от совершенства. Для обеспечения бесперебойной работы надо постоянно учитывать этот фактор и быть немного психологом. Нам надо не только задизайнить архитектуру, которые в принципе могут работать без сбоев, но и попытаться исключить ошибки операторов, других инженеров в процессе эксплуатации и последующих доработок — иначе высоких показателей надежности не получится.
Когда выясняется, что в сбое виноват кто-то конкретный, а по причинам изложенным выше так рано или поздно оказывается всегда — появляется соблазн начать ругать и обвинять сотрудников компании в сложившейся ситуации. Но практика показала, что это контр-продукттивно. Люди начинают скрывать свои ошибки, или вместо реальной ситуации или причин показыват более извинительные. В результате ситуация становится хуже.
Поэтому часто при работе со сбоями практикуют необвинительную культуру, когда за ошибки людей не ругают и не штрафуют. Напротив создают доверительную и психологически безопасную среду, где можно спокойно обсудить действия разных людей и выработать стратегию улучшения ситуации.
В начале работы в Google мне часто рассказывали следующую цепочку рассуждений: если человек успешно получил образование, прошел сложное собеседование, получил работу, прошел испытательный срок, сделал много сложных вещей и все-равно в чем-то ошибся, то это не его вина. Скорее всего в подобной ситации ошиблись бы многие, надо разобраться, понять каким образом произошла ошибка и попытаться ее исключить в дальнейшем. То есть в данном случае человек просто первый наступивший на эти грабли и винить его в этом — бессмысленно и вредно.
Стоит упомянуть, что необвинительная культура не касается случаев намеренного приченения ущерба.
Чем занимаются SRE
SRE — инженерная специальность. Специалисты занимаются все м тем, чем и другие инженеры: проектированием, наладкой, устранением неполадок, эксплуатацией, выведением из эксплуатации, утилизацией.
Мониторинг
Одна из важных задач SRE — мониторинг. Они проектируют метрики и логи, чтобы приложение в удобном виде рассказывало о том, что нужно и не более, потому что перегрузка информацией так же губительна, как и ее недостаток.
В чем состоит работа:
- помощь командам в дизайне и мониторинге сервисов
- дизайн и реализация мониторинга доступности
- журналирование важных событий в жизни софта
Алертирование
- выстраивание процессов доставки и реагирования на алерты
- анализ качества реагирования на алерты
Задача настройки грамотного алертирования очень сложна. Часто алертирование получается шумным — в месседжер приходит дикое количество сообщений, важные сообщения в таком случае часто пропускаются.
Устранение сбоев
Устранение сбоев должно быть быстрым. SRE, как правило непосредственно устраняют неполадки в сервисах.
- реагирование на алерты и восстановление работоспособности системы
- уведомление о сбоях
- координация работ по устранению сбоев
В случае крупного сбоя, когда задействовано много элементов от разных команд, важно грамотно рассказать о сбое другим инженерам, а когда все становится совсем плохо, то и службе поддержки и PR-службе. Грамотная внешняя коммуникация может существенно уменьшить негатив пользователей и итоговый ущерб.
Анализ сбоев
Чтобы понимать общую ситуацию и принимать обоснованные решения необходимо постоянно анализировать прошлые сбои и собирать статистику.
- изучать статистику сбоев
- выявлять самые частые причины сбоев
- искать пути улучшения на основании прошлых сбоев
- бюджетировать простои
При анализе сбоев часто их делят на категории по причинам. Мы так же делали у себя. Инженеры выбирали причины из списка в нашей информационной системе. Среди причин был пункт релиз и он выбирался довольно часто.
Позже я убрал этот пункт — релиз не может быть причиной сбоя, так как это просто обязательный этап в жизненном цикле приложения. Тогда все эти сбои стали попадать совсем в другую категорию — баг в приложении.
Это простое действие произвело большую революцию в головах. Вместо того, чтобы обсуждать, почему мы делаем "плохие релизы", мы стали обсуждать, почему мы так плохо тестируем приложения. Даже то, какую классификацию причин сбоев вы используете, приломившись в головах людей, повлияет на вашу компанию неожиданным образом.
Обучение
Обученный человек ошибается реже, чем не обученный. Поэтому одним только обучением можено уменьшить количество сбоев.
Если обучением не занимаются, то нового человека в компании сначала посадят делать рутинные задачи. Через пару-тройку месяцев посчитают, что он уже достаточно понахватался и можно поставить на дежурство и отвечать за софт. В результат у него может не оказаться нужных знаний в момент сбоя когда-нибудь ночью, когда коллеги не доступны. Бороться с этим скучно, но не сложно — любой SRE должен проходить системное обучение конкретной системе, которую будет обслуживать и сдать экзамен для контроля.
Доставка новых версий приложений
Релиз не является причиной сбоя, но часто является его триггером. Есть способы делать релизы более безопасными:
– blue-green deployment,
- использование канареек
- использование переключателей функционала
Все эти приемы мы рассмотрим в последующих лекциях.
Планирование восстановления после катастроф и отработка этих планов
Существуют очень масштабные сбои, когда мы теряем данные и нужно восстанавливать из бэкапов по многим системам. Нужно иметь план на случай таких ситуаций. Этот план надо тестировать.
Существует два термина DRP (Disaster Recovery Plan) и DiRT (Disaster Recovery Testing).
Отказоустойчивость архитектур систем
Часто существенно повлиять на количество сбоев можно только переработав архитектуру системы. SRE должен обладать компетенцией в этой сфере иначе его возможности будут сильно ограничены.
Интересно, что на надежность архитектуры влияет даже ее понятность. Если архитектуру можно объяснить за час, то понимание ее коллегами будет выше и устойчивость тоже выше из-за меньшего количества ошибок.
Обеспечение вычислительными ресурсами
Важно понимать, сколько необходимо ресурсов, заранее их покупать и устанавливать. Важно знать долгосрочные тренды, пиковые моменты. Приложения бывают загружены нелинейно. Например, в инвестиционных приложениях один твит может дать гигантскую нагрузку. На пике сезона нагрузка на приложения магазинов может повышаться кратно. Надо следить за наличием ресурсов и своевременно их пополнять.
Когда Google рекламирует по ТВ ассистента и в рекламе говорится «окей, Google». То реагируют миллионы устройств пользователей. В прайм-тайм это очень большая нагрузка на ассистента и для этого принимаются специальные меры.
Тестирование
SRE настолько суровы, что тестируют в продакшен.
Тестирование в продакшен часто вызывает дискуссии — допустимо или нет. Но до продакшна все тесты – искусственные. А настоящий и финальный тест будет всегда после релиза на пользователях. Поэтому правильный вопрос не в том тестировать или нет, а в том готовиться ли к такому тестированию или нет.
Для безопасного тестирования в продакшен придумано множество инструментов. Если сделать совсем хорошо, то можно больше доверять тестам в продакшен и меньше тестировать до него — уменьшится время поставки нового функционала. Но для этого надо очень сильно подготовить свой продакшен к такому.
Конфигурирование приложений
Конфигурирование приложений и систем — искусство SRE. Из-за ошибки в конфигурации даже разорился Knight Capital Group.
Классическая ошибка — во время сбоя делается переконфигурирование, а после устранения никто не помнит внесенные правки. Вернуться к изначальному состоянию сложно, так что это не делается, а в будущем появляются новые проблемы.
Разработка общих инструментов обеспечения отказоустойчивости
SRE могут помочь разработке библиотеками для типовых случаев: переключатели, таймауты, трассировка запросов, другие инструменты, которые используются для обеспечения отказоустойчивости или быстрого устранения случившихся сбоев.
Публикация сервисов
Публикация сервисов наружу — ответственная часть, которая может провоцировать сбои или наоборот уменьшать их сама по себе, например, переводя запросы пользователя из сбойного датацентра в рабочие.
Так же на этом уровне часто решаются задачи по противодействию DDOS атакам, что так же уменьшает количество сбоев наших сетвисов.
Документирование
Сбои происходят не только от багов, но и от отсутствия документации, от того, что она устарела, или от того, что сотрудники ее не читают (откладывают знакомство на момент сбоя). Документации не должно быть слишком много (быстрее устаревает) или слишком мало.
Документация должна быть в месте использования, а не на вики.
Так детали работы с конфигом лучше написать в его шапку. Тогда вероятность, что ее прочитают при правке конфига многократно вырастает.
Выводы
У SRE черезвычайно широкий круг интересов и обязанностей: от процессов разработки и архитектуры до кода и тестирования.
Обычно грамотный SRE — не новичок, а человек с большим стажем. Важно знать всего понемножку. Эксплуатация софта задействует все навыки, которые есть у людей разных профессий в IT.
SRE в большей степени обращает внимание не на фичи, а на то, как ПО сделано.
Различия между DevOps и SRE
Работа SRE может напоминать работу DevOps-инженера.
Давайте разберемся. У термина DevOps есть два значения, которые противоречат друг другу. Первое – оригинальное. DevOps = Dev + Ops. Разработка + операции. Если разработка ПО происходит внутри вашей компании, то не нужно отделять команду разработчиков от команды администраторов. Эффективнее работать единой командой, потому что улучшается коммуникация. Принцип Amazon: Уou build it – you run it (вы сделали — вам и эксплуатировать).
Современное понимание развернулось на 180 градусов. Команда разработки пишет софт, затем отдельная команда DevOps его выкладывает. Одна команда DevOps часто обслуживает много команд разработчиков. В этом случае люди называют DevOps людей, которые выкладывают новые версии софта, занимаются настройкой сопустствующих баз данных, CI/CD процессов, мониторинга.
Первое понимание термина ни в чем не противоречит SRE.
Во втором, как правило, DevOps-инженеры в отличие от SRE не смотрят в архитектуру, не должны уметь писать код, не работают с надежностью непосредственно — только устраняют сбои, но не воздействуют на разработку и устранение причин.